Support `DefKind::InlineConst` in `ConstKind::Unevaluated` by khyperia · Pull Request #158375 · rust-lang/rust

khyperia · 2026-06-24T18:39:20Z

fixes rust-lang/project-const-generics#101

required for rust-lang/project-const-generics#108

consider: Struct<{ (some, stuff, const { hi }) }>. The following is very pseudocode-y, the important parts are whether it says AnonConst or InlineConst, not the Tuple stuff

On stable, we represent this with: AnonConst(Tuple(some, stuff, InlineConst(hi)))
Under mGCA, with "direct" arguments, before this PR, it was Tuple(some, stuff, AnonConst(hi)). The inner InlineConst got intercepted in the def_collector with hacks (ConstArgContext) and converted into an AnonConst, even though it has inline const syntax.

It would be nice to keep it as an InlineConst under mGCA, i.e. Tuple(some, stuff, InlineConst(hi)), and have the type system support passing around InlineConsts in ConstKind::Unevaluated (soon to be renamed ConstKind::Alias). This would allow the def collector to not need to know if we are in a "direct" or "regular/anon" context, which it turns out is extremely useful for implementing rust-lang/project-const-generics#108. Supporting InlineConsts in the type system are also useful for other things, for example, mentioned in rust-lang/project-const-generics#101 is arg position const generics experiments.

This PR does two things:

support InlineConsts in the type system (i.e. in ConstKind::Unevaluated)
exercise that support, by no longer intercepting mGCA "direct" argument inline consts to be anon consts

r? @BoxyUwU

rustbot · 2026-06-24T18:39:24Z

HIR ty lowering was modified

cc @fmease

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

BoxyUwU

did u look through all of DefKind::InlineConst/DefKind::AnonConst or is this just the stuff that when not updated breaks the test suite?

View changes since this review

rustbot · 2026-06-27T08:54:57Z

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

khyperia · 2026-06-27T08:56:17Z

did u look through all of DefKind::InlineConst/DefKind::AnonConst or is this just the stuff that when not updated breaks the test suite?

Looked through them all! Went through them all again just now to be sure. Here's a list of things that might be notable for you (to double check my looking-through-them-all):

I missed this one!! Added now. The fact it was missing happened to have exactly the same (and correct) behavior as what I changed it to, but it's nice to be explicit.

rust/compiler/rustc_hir_typeck/src/loops.rs

Line 86 in 1676160

DefKind::AnonConst => AnonConst,
- It is currently impossible to hit loops.rs visit_inline_const with a type system inline const, that newly written if statement in my change is "dead" code, but it's nice to be explicit IMO.
  edit: wait no, uuh, type system inline consts are always hir::AnonConst, they can't be hir::ConstBlock, so maybe I should delete the if?
There's some GCE uses of AnonConst that I have left for now.
The alias_term_kind_from_def_id vs. unevaluated_const_kind_from_def_id which we discussed in DMs. Maybe I should just add it...
The FCW cannot use constants which depend on generic parameters in types, I don't think it's possible to get here with the current use case and adding an InlineConst case would be impossible-to-test dead code, so I'm not sure how to properly test it. Maybe I should just blindly add a type system InlineConst case here, I don't know.
I'm 95% sure this backcompat jank around const fn promotion is fine (the only use of the inline field is that ConstContext::Const allow_const_fn_promotion is later initialized with !inline). I thiiink, because it's only called in MIR stuff, MIR should only see non-type-system InlineConsts.

rust/compiler/rustc_middle/src/hir/map.rs

Line 328 in 1676160

DefKind::InlineConst => BodyOwnerKind::Const { inline: true },

@rustbot ready (except you didn't do rustbot author :P)

khyperia · 2026-06-27T09:43:34Z

Updated with the stuff I was unsure of in the previous comment.

Also moved a comment that was wonkily placed IMO (due to #158360 )

Shourya742

Looks awesome to me (learnt new stuff) 🚀 Thanks.

View changes since this review

BoxyUwU · 2026-06-29T15:44:39Z

@bors r+

thx ashley and thx shourya for the reviews, much appreciated :3

rust-bors · 2026-06-29T15:44:42Z

📌 Commit f31f522 has been approved by BoxyUwU

It is now in the queue for this repository.

@BoxyUwU

…tem, r=BoxyUwU Support `DefKind::InlineConst` in `ConstKind::Unevaluated` fixes rust-lang/project-const-generics#101 required for rust-lang/project-const-generics#108 consider: `Struct<{ (some, stuff, const { hi }) }>`. The following is very pseudocode-y, the important parts are whether it says AnonConst or InlineConst, not the Tuple stuff - On stable, we represent this with: `AnonConst(Tuple(some, stuff, InlineConst(hi)))` - Under mGCA, with "direct" arguments, before this PR, it was `Tuple(some, stuff, AnonConst(hi))`. The inner InlineConst got intercepted in the def_collector with hacks (`ConstArgContext`) and converted into an AnonConst, even though it has inline const syntax. It would be nice to keep it as an InlineConst under mGCA, i.e. `Tuple(some, stuff, InlineConst(hi))`, and have the type system support passing around InlineConsts in `ConstKind::Unevaluated` (soon to be renamed `ConstKind::Alias`). This would allow the def collector to not need to know if we are in a "direct" or "regular/anon" context, which it turns out is extremely useful for implementing rust-lang/project-const-generics#108. Supporting InlineConsts in the type system are also useful for other things, for example, mentioned in rust-lang/project-const-generics#101 is arg position const generics experiments. This PR does two things: - support InlineConsts in the type system (i.e. in `ConstKind::Unevaluated`) - exercise that support, by no longer intercepting mGCA "direct" argument inline consts to be anon consts r? @BoxyUwU

Rollup of 12 pull requests Successful merges: - #158073 (bootstrap: fix panic when repo path contains spaces by switching to CARGO_ENCODED_RUSTFLAGS) - #158169 (Fix debuginfo compression in bootstrap) - #158256 (Avoid parser panics bubbling out to proc macros) - #158375 (Support `DefKind::InlineConst` in `ConstKind::Unevaluated`) - #158417 (Avoid ICE when cfg_eval recovers no item from derive input) - #158556 (delegation: store child segment flag in `PathSegment`) - #158561 (Avoid building rustdoc for tests without doctests) - #158562 (Improve tracing of steps in bootstrap) - #157445 (Allow section override when using patchable-function-entries) - #158081 (trait-system: Recover deferred closure calls after errors) - #158327 (Move attribute and keyword docs from `std` to `core`) - #158468 (Include default-stability info in rustdoc JSON.)

@BoxyUwU

…tem, r=BoxyUwU Support `DefKind::InlineConst` in `ConstKind::Unevaluated` fixes rust-lang/project-const-generics#101 required for rust-lang/project-const-generics#108 consider: `Struct<{ (some, stuff, const { hi }) }>`. The following is very pseudocode-y, the important parts are whether it says AnonConst or InlineConst, not the Tuple stuff - On stable, we represent this with: `AnonConst(Tuple(some, stuff, InlineConst(hi)))` - Under mGCA, with "direct" arguments, before this PR, it was `Tuple(some, stuff, AnonConst(hi))`. The inner InlineConst got intercepted in the def_collector with hacks (`ConstArgContext`) and converted into an AnonConst, even though it has inline const syntax. It would be nice to keep it as an InlineConst under mGCA, i.e. `Tuple(some, stuff, InlineConst(hi))`, and have the type system support passing around InlineConsts in `ConstKind::Unevaluated` (soon to be renamed `ConstKind::Alias`). This would allow the def collector to not need to know if we are in a "direct" or "regular/anon" context, which it turns out is extremely useful for implementing rust-lang/project-const-generics#108. Supporting InlineConsts in the type system are also useful for other things, for example, mentioned in rust-lang/project-const-generics#101 is arg position const generics experiments. This PR does two things: - support InlineConsts in the type system (i.e. in `ConstKind::Unevaluated`) - exercise that support, by no longer intercepting mGCA "direct" argument inline consts to be anon consts r? @BoxyUwU

@BoxyUwU

…tem, r=BoxyUwU Support `DefKind::InlineConst` in `ConstKind::Unevaluated` fixes rust-lang/project-const-generics#101 required for rust-lang/project-const-generics#108 consider: `Struct<{ (some, stuff, const { hi }) }>`. The following is very pseudocode-y, the important parts are whether it says AnonConst or InlineConst, not the Tuple stuff - On stable, we represent this with: `AnonConst(Tuple(some, stuff, InlineConst(hi)))` - Under mGCA, with "direct" arguments, before this PR, it was `Tuple(some, stuff, AnonConst(hi))`. The inner InlineConst got intercepted in the def_collector with hacks (`ConstArgContext`) and converted into an AnonConst, even though it has inline const syntax. It would be nice to keep it as an InlineConst under mGCA, i.e. `Tuple(some, stuff, InlineConst(hi))`, and have the type system support passing around InlineConsts in `ConstKind::Unevaluated` (soon to be renamed `ConstKind::Alias`). This would allow the def collector to not need to know if we are in a "direct" or "regular/anon" context, which it turns out is extremely useful for implementing rust-lang/project-const-generics#108. Supporting InlineConsts in the type system are also useful for other things, for example, mentioned in rust-lang/project-const-generics#101 is arg position const generics experiments. This PR does two things: - support InlineConsts in the type system (i.e. in `ConstKind::Unevaluated`) - exercise that support, by no longer intercepting mGCA "direct" argument inline consts to be anon consts r? @BoxyUwU

@BoxyUwU

…tem, r=BoxyUwU Support `DefKind::InlineConst` in `ConstKind::Unevaluated` fixes rust-lang/project-const-generics#101 required for rust-lang/project-const-generics#108 consider: `Struct<{ (some, stuff, const { hi }) }>`. The following is very pseudocode-y, the important parts are whether it says AnonConst or InlineConst, not the Tuple stuff - On stable, we represent this with: `AnonConst(Tuple(some, stuff, InlineConst(hi)))` - Under mGCA, with "direct" arguments, before this PR, it was `Tuple(some, stuff, AnonConst(hi))`. The inner InlineConst got intercepted in the def_collector with hacks (`ConstArgContext`) and converted into an AnonConst, even though it has inline const syntax. It would be nice to keep it as an InlineConst under mGCA, i.e. `Tuple(some, stuff, InlineConst(hi))`, and have the type system support passing around InlineConsts in `ConstKind::Unevaluated` (soon to be renamed `ConstKind::Alias`). This would allow the def collector to not need to know if we are in a "direct" or "regular/anon" context, which it turns out is extremely useful for implementing rust-lang/project-const-generics#108. Supporting InlineConsts in the type system are also useful for other things, for example, mentioned in rust-lang/project-const-generics#101 is arg position const generics experiments. This PR does two things: - support InlineConsts in the type system (i.e. in `ConstKind::Unevaluated`) - exercise that support, by no longer intercepting mGCA "direct" argument inline consts to be anon consts r? @BoxyUwU

…uwer Rollup of 16 pull requests Successful merges: - #155722 (Introduce aarch64-unknown-linux-pauthtest target) - #156230 (tests: check wasm compiler_builtins object architecture) - #158073 (bootstrap: fix panic when repo path contains spaces by switching to CARGO_ENCODED_RUSTFLAGS) - #158169 (Fix debuginfo compression in bootstrap) - #158256 (Avoid parser panics bubbling out to proc macros) - #158375 (Support `DefKind::InlineConst` in `ConstKind::Unevaluated`) - #158556 (delegation: store child segment flag in `PathSegment`) - #158561 (Avoid building rustdoc for tests without doctests) - #158562 (Improve tracing of steps in bootstrap) - #157445 (Allow section override when using patchable-function-entries) - #158081 (trait-system: Recover deferred closure calls after errors) - #158327 (Move attribute and keyword docs from `std` to `core`) - #158468 (Include default-stability info in rustdoc JSON.) - #158564 (fix `-Z min-recursion-limit` unstable chapter name) - #158568 (llvm-wrapper: use accessors for private fields in LLVM 23+) - #158582 (Comment on needed RAM in huge-stacks.rs)

…uwer Rollup of 11 pull requests Successful merges: - #155722 (Introduce aarch64-unknown-linux-pauthtest target) - #156230 (tests: check wasm compiler_builtins object architecture) - #156295 (Pass the whole `GenericArgs` to `Interner::for_each_relevant_impl()`) - #158375 (Support `DefKind::InlineConst` in `ConstKind::Unevaluated`) - #158556 (delegation: store child segment flag in `PathSegment`) - #158081 (trait-system: Recover deferred closure calls after errors) - #158468 (Include default-stability info in rustdoc JSON.) - #158543 (Note usage of documentation hard links in `core::io`) - #158564 (fix `-Z min-recursion-limit` unstable chapter name) - #158568 (llvm-wrapper: use accessors for private fields in LLVM 23+) - #158582 (Comment on needed RAM in huge-stacks.rs)

@BoxyUwU

Rollup merge of #158375 - khyperia:inline-consts-in-type-system, r=BoxyUwU Support `DefKind::InlineConst` in `ConstKind::Unevaluated` fixes rust-lang/project-const-generics#101 required for rust-lang/project-const-generics#108 consider: `Struct<{ (some, stuff, const { hi }) }>`. The following is very pseudocode-y, the important parts are whether it says AnonConst or InlineConst, not the Tuple stuff - On stable, we represent this with: `AnonConst(Tuple(some, stuff, InlineConst(hi)))` - Under mGCA, with "direct" arguments, before this PR, it was `Tuple(some, stuff, AnonConst(hi))`. The inner InlineConst got intercepted in the def_collector with hacks (`ConstArgContext`) and converted into an AnonConst, even though it has inline const syntax. It would be nice to keep it as an InlineConst under mGCA, i.e. `Tuple(some, stuff, InlineConst(hi))`, and have the type system support passing around InlineConsts in `ConstKind::Unevaluated` (soon to be renamed `ConstKind::Alias`). This would allow the def collector to not need to know if we are in a "direct" or "regular/anon" context, which it turns out is extremely useful for implementing rust-lang/project-const-generics#108. Supporting InlineConsts in the type system are also useful for other things, for example, mentioned in rust-lang/project-const-generics#101 is arg position const generics experiments. This PR does two things: - support InlineConsts in the type system (i.e. in `ConstKind::Unevaluated`) - exercise that support, by no longer intercepting mGCA "direct" argument inline consts to be anon consts r? @BoxyUwU

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jun 24, 2026

rustbot assigned BoxyUwU Jun 24, 2026

BoxyUwU reviewed Jun 26, 2026

View reviewed changes

Comment thread compiler/rustc_resolve/src/def_collector.rs Outdated

Comment thread compiler/rustc_resolve/src/def_collector.rs Outdated

Comment thread compiler/rustc_ty_utils/src/sig_types.rs

This comment has been minimized.

Sign in to view

khyperia force-pushed the inline-consts-in-type-system branch from a238c1d to 013f793 Compare June 27, 2026 08:54

khyperia force-pushed the inline-consts-in-type-system branch from 013f793 to 4a41270 Compare June 27, 2026 09:39

Shourya742 reviewed Jun 27, 2026

View reviewed changes

Comment thread compiler/rustc_hir_analysis/src/hir_ty_lowering/mod.rs Outdated

Support DefKind::InlineConst in UnevaluatedConst

f31f522

khyperia force-pushed the inline-consts-in-type-system branch from 4a41270 to f31f522 Compare June 27, 2026 15:50

Shourya742 approved these changes Jun 28, 2026

View reviewed changes

rust-bors Bot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 29, 2026

jhpratt mentioned this pull request Jun 29, 2026

Rollup of 12 pull requests #158570

Closed

JonathanBrouwer mentioned this pull request Jun 29, 2026

Rollup of 14 pull requests #158578

Closed

JonathanBrouwer mentioned this pull request Jun 29, 2026

Rollup of 14 pull requests #158581

Closed

JonathanBrouwer mentioned this pull request Jun 29, 2026

Rollup of 16 pull requests #158584

Closed

JonathanBrouwer mentioned this pull request Jun 30, 2026

Rollup of 11 pull requests #158593

Merged

rust-bors Bot merged commit 0c58e97 into rust-lang:main Jun 30, 2026
13 checks passed

rustbot added this to the 1.98.0 milestone Jun 30, 2026

khyperia deleted the inline-consts-in-type-system branch June 30, 2026 08:49

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

Support `DefKind::InlineConst` in `ConstKind::Unevaluated`#158375

Support `DefKind::InlineConst` in `ConstKind::Unevaluated`#158375
rust-bors[bot] merged 1 commit into
rust-lang:mainfrom
khyperia:inline-consts-in-type-system

khyperia commented Jun 24, 2026 •

edited by rustbot

Loading

Uh oh!

rustbot commented Jun 24, 2026

Uh oh!

BoxyUwU left a comment •

edited

Loading

Uh oh!

Uh oh!

Uh oh!

Uh oh!

This comment has been minimized.

rustbot commented Jun 27, 2026

Uh oh!

khyperia commented Jun 27, 2026 •

edited

Loading

Uh oh!

khyperia commented Jun 27, 2026

Uh oh!

Uh oh!

Shourya742 left a comment •

edited by rustbot

Loading

Uh oh!

BoxyUwU commented Jun 29, 2026

Uh oh!

rust-bors Bot commented Jun 29, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Uh oh!

Uh oh!

Conversation

khyperia commented Jun 24, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Jun 24, 2026

Uh oh!

BoxyUwU left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

This comment has been minimized.

rustbot commented Jun 27, 2026

Uh oh!

khyperia commented Jun 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

khyperia commented Jun 27, 2026

Uh oh!

Uh oh!

Shourya742 left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

BoxyUwU commented Jun 29, 2026

Uh oh!

rust-bors Bot commented Jun 29, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

khyperia commented Jun 24, 2026 •

edited by rustbot

Loading

BoxyUwU left a comment •

edited

Loading

khyperia commented Jun 27, 2026 •

edited

Loading

Shourya742 left a comment •

edited by rustbot

Loading